Business Analyst Community & Resources | Modern Analyst

Thoughts on the Agile Extension of the BABOK

Jarett Hailes — Thu, 01 Mar 2012 02:23:00 GMT

Today was the last day people could provide feedback to the IIBA’s Agile Extension of the BABOK. The most recent draft of the document was published in November 2011 for review and comment. The purpose of the extension is to provide readers an understanding of how business analysis can be performed within an Agile environment. Various Agile methodologies such as Scrum, XP and Kanban are presented in high level summaries, and then business analysis activities from the BABOK are mapped to the main events that occur in the general Agile environment. Finally, a list of techniques that can be applied to the BABOK activities in an Agile setting are presented.

Overall the document is well written and does a good job of describing how business analysis fits into an Agile setting. This is a topic that has been much discussed in the past few years, and two years ago I wrote an article that summarized several leading Agile experts’ views on how the Business Analyst role fits into the evolving Agile framework. As Agile methodologies continue to gain traction in corporate software development processes, it makes sense to ensure that Business Analysts feel comfortable with how their skills transition to a different environment.

That said I have a concern about having such an extension does to the perception of business analysis as a profession and to Business Analysts as a role. I do not see business analysis as some activity that is merely a component of software development or IT solution delivery. Business Analysts can play a strategic role in the organization to help ensure that the organization is capitalizing on its opportunities and adapts efficiently to changing market, regulatory and internal cultural changes. When BAs are deployed throughout an organization they can get a hands on sense of what’s working, what’s not, and can draw upon technical and behavioural expertise to find innovative ways to help the organization continually improve its operations. I have had the opportunity with several clients to step outside of IT departments and play such a role, and not only is it personally rewarding but it is also where I have been able to provide the most value.

In many organizations I come into contact with business analysis is perceived as some 'IT thing' done to 'help the techies figure out what the business wants'. This perception often comes found the originations of professional business analysis, and while understandable, it is something that must be challenged in order to unlock the potential of having professional Business Analysts throughout the organization working on problems that are not limited to an IT solution scope.

The second version of the BABOK made great strides towards demonstrating how business analysis can be performed outside of IT and explained why it is needed by organizations to adapt to today's constantly changing environments. While some organizations are starting to see the value of BAs outside of IT, having a document such as the Agile extension reinforces existing preconceptions of business analysis in a limited role. In some ways publishing an Agile extension seems like a mea culpa to the wider business audience, indicating that it is wrong to think of business analysis outside of a software development context. I am sure this is not the intention of the IIBA, but given the stage of development of the profession it may be an unintended consequence.

I have been meeting with several executives, managers of Business Analysts and consulting business development personnel in a study group of the BABOK. Through their reading and discussion of the BABOK’s concepts they have come to recognize the value of the information outside of an IT setting, which has taken some work given that while the BABOK V2 is more generic than before, many of the concepts and examples rely heavily on the IT domain. When I mentioned that there was now an Agile extension, most wondered if in fact we had all been reading too deeply into the BABOK; maybe it was just for IT environments after all.

Perhaps I am being too harsh on having such an extension – after all the Project Management Institute has a construction industry extension to the PMBOK, which is one of the industries that were a main influence in the beginning of the institute, as well as for government. The PMI even has an Agile practitioner certification, which is decidedly focused on software development. Nonetheless, I feel that given the developmental stage of business analysis as a profession, having such an extension sends mixed messages on the applicability of the body of knowledge, and limits the career opportunities for Business Analysts in the near term.

As I mentioned above I think the content is valuable and good for BAs who are working in the IT domain to know, but I believe that some other term may be been better suited to describing the document. Calling it an extension of the BABOK ties it too heavily to the general body of knowledge in my mind. I could have seen this as a valuable ‘industry application guide’ or something along those lines.

What are your thoughts on the Agile extension? Do you like the content? What do you think that such an extension does to the perception of business analysis in general and outside of the IT domain in particular?

Business Analysis Conference Europe 2010

Adrian M. — Sun, 08 Aug 2010 06:36:00 GMT

The Business Analysis Conference Europe 2010 is building on its highly successful inaugural conference with more workshops and a third track – Business Agility and Business Analysis. It brings together business analysis specialists from across Europe and beyond, providing a platform for promoting the BA profession and opportunities for BAs’ professional development.

The conference runs from 28th to 30th September 2010.

This year we have partnered with the IIBA UK to run an online pre Conference series. Conference speakers will be providing articles to give a real insight into the benefits of attending the Business Analysis Conference in Europe.

One of the keynote speakers, John Seddon, has contributed a piece on the Systems approach to the design and management of service organisations.
The Telegraph described John as a 'reluctant management guru', a description John accepts as his interest is in changing management thinking.

(John Seddon’s key note Conference contribution is described here)

Ellen Gottesdiener and Allan Kelly who are recognized experts on Agile, will share their views on business analysis and Agile from both sides of the pond.

(Ellen Gottesdiener’s Conference contribution is described here)
(Allan Kelly’s Conference contribution is described here)

Joe Da Silva is an experienced business analyst for Skandia who will explore the diverse roles a business analyst can play. (His conference presentation explores his experience in Enterprise Analysis when his organisation recognized the benefits of using internal business analysts instead of expensive, external consultants).

(Joe Da Silva’s Conference contribution is described here)

These are just a few of the articles that are planned and there may be a webinar in the last couple of weeks prior to the conference.

Business analysis is now the central discipline for defining creative and agile options for business change and ensuring that solutions meet business needs. The Business Analysis Conference 2010 will provide an interactive forum where business analysts can learn and debate the essential competencies needed to rise to the challenges faced by their organisations today and in the future.

Read more about the Business Analysis Conference Europe 2010 here.

IMPORTANT DISCOUNTS:
There is a 10% discount available to IIBA members and 15% available to members of the UK Chapter. There is also a discount of up to 25% for group bookings.

Modern Analyst members and Business Analyst Mentor (www.bamentor.com) readers qualify for a 10% discount (Note: this cannot be combined with any other discounts).

Mitigating the Risk of Story Point Drift

Jarett Hailes — Mon, 18 Jan 2010 01:38:00 GMT

In many Agile projects requirements are not typically written in the form of a formal requirements document. Instead, a collection of concise but effective means of describing what must be built called user stories are often used. User stories describe the behaviour, performance, or interface of a system from a customer’s perspective. A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artifacts, they are also essential to estimate the scope/size of the project and to track the progress of the team. When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject).

Agile teams will often use a unit-free type of measure called story points. The advantage of using story points is that their inherent value is relative. Instead of trying to come up with absolute values typically related to time (for instance, how many days will it take to complete feature X), story points are only concerned about the relative effort or complexity of a story compared to the other stories that have been or need to be completed. When the total number of story points for the project is combined with a team’s velocity (the number of story points completed per iteration period) project stakeholders are able to get an increasingly accurate picture of the size of the project and the time it will take to complete given the current team.

Initially when the team forms they will estimate story points for some number of baseline stories. For instance, the team may have the following 3 stories as their baseline:

As a user I want to browse the book collection by subject: 8 points

As a user I want to be able to save my payment information: 2 points

As a user I want to be able to recommend my favorite books to people: 5 points

From this baseline other user stories are estimated in terms of their perceived relative amount of effort to accomplish. For larger projects, most user stories are estimated as epics, larger user stories that will be broken down later on in order to actually tackle development.

Over time, new user stories will be added to the product backlog, others removed and some will be altered to reflect changing requirements. All the stories that are added or changed to the backlog will require story point estimation.

One of the potential risks that exists when using story points is what I call ‘story point drift’. Story point drift is when user stories that had a given story point value at the beginning of the project require substantially more or less effort than stories with the same story point value later on in the project for the given amount of effort required to complete a story.

For instance, let’s say I have the following user stories estimated later in the project:

As a user I want to be able to have my bank account linked to my login and set up a monthly withdrawal plan: 8 points

As a user I want to have a theme editor that can customize the look and feel of my online affiliate store: 5 points

While the above user stories may accurately represent their relative size compared to each other, in comparison to the stories that were estimated at the onset of the project it appears as though the latter group’s story points under-represent their complexity and level of effort required. I would suspect that the amount of work to enable automatic bank transactions is substantially larger than the amount of effort required to build a browse by subject feature.

I find the risk of story point drift increases on larger or longer-term Agile projects. Story point drift can occur for several reasons:

The team’s collective memory is short term: when a team begins estimating new stories, they typically draw upon their experiences from recently completed stories. If some of those stories were misclassified (either required materially more or less relative effort than was represented in the story point estimate), then the team can end up believing that these recent stories are the new norm for the value of the story points and use these as references going forward, which skew the story point values from the original baseline references.

The team’s complement has changed: it is not uncommon for project teams to change over time. I’ve noticed that even as teams get larger or smaller that a team’s velocity can appear to remain constant. When investigating this, I’ve found that it’s often because the team begins to estimate stories with fewer points, since they now feel that the story is ‘easier’ since there are more people to work on the project. As a result stories that might have been considered 8 points previously are now being estimated as 5 points. As a result, despite the fact that the team is likely getting more done given their drift in estimates the team’s velocity appears unchanged.

Baselines are not referred to: Agile projects usually thrive by the minimization of overhead that does not lead to customer value and by adapting to non-ideal situations. For example, Agile teams rarely wait for everyone to show up for a meeting – the meeting is time-boxed and starts and ends on time regardless of who is missing. However, at times Agile teams may forget to bring physical objects like their reference stories to meetings. Sometimes teams will try and get through the meeting based on recollection rather than actual reference. Without the actual reference stories and point values in hand, the resulting estimates can be somewhat skewed.

When I’ve seen story point drift it has occurred in small increments over time – you don’t realize that there’s been a dramatic deviation in the estimates until sometimes months later. Story point drift can cause issues with resource planning and progress and time to completion estimation. Here are a couple of strategies I’ve used to help mitigate story point drift:

Bring mixture of original and recent stories as the baseline for new estimation: it never hurts to hold up your original estimates when doing relative comparisons. Having some recent examples are also helpful, in particular since your initial estimates were likely only for a few potential story point values. Having 1 or 2 stories for each possible story point value can also be helpful when discussing what level of estimate to assign to a new story, or when individuals are deadlocked in a session of planning poker.

Know when certain stories should be re-estimated after implementation: once in awhile you will encounter a story that was a lot more (or less) effort than you initially thought. If the level of effort was sufficiently different from another story that was given the same amount of points, you may want to re-estimate the story so that it does not affect your team’s perception of the value of a certain number of story points. I typically would only re-estimate a story once a project has been going for several Sprints – early on you may discover that many of your stories take less or more effort than you thought and you’ll be tempted to resize those stories. However, as long as the stories are taking about the same amount of relative effort, then there’s no need to re-estimate. So if you thought your 3 point stories would take a day to complete but they’re taking the better part of a week, check to see how your 5 and 8 point stories are taking. If those are also taking a fair bit longer than anticipated, then don’t re-estimate.

Spend a little time every few Sprints and analyze relative stories: the ScrumMaster or Project Manager can review some of the completed stories over time to look for possible story point drift. If some drift is detected, bring it up with the team and see what they think. If the team agrees, then re-estimate the stories that appear to be out of what in terms of relative effort.

User stories and story points can be a very good way to manage the requirements and estimation for a project. Keeping an eye on story point drift will ensure that the team has a good handle on the project’s rate of progress and estimated time to completion. With diligence this method of project estimation can be a very accurate and effective tool for Agile teams.

-------

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Agile Development: What we can learn from property developers – or what they’ve learned from us

Howard Podeswa — Sun, 13 Dec 2009 05:01:00 GMT

Readers of this blog (both of you; I know you’re out there!) may have gathered by now that I’m a big fan of mixing it up: art/science/business/philosophy/politics/psychology and anything else that can be thrown into the pot. I believe that the more you let your worlds bleed into each other, the more opportunity there is to benefit from the cross-pollination of ideas.

I had a vivid example of this recently. I was having dinner with a friend of mine – who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground.

Sound familiar? What he was describing was iterative-incremental development – an approach to managing software projects that is the basis of agile approaches, IBM’s RUP (Rational Unified Process) and Microsoft’s MSF.

It’s interesting to note that the classic (i.e. older) approach to managing software projects was based on the how the construction industry managed its projects at that time: a single cycle of requirements analysis, design, testing and construction, known in the IT world as the ‘waterfall’ approach. That got me wondering whether the influence is now flowing on the opposite direction. Are managers of construction projects now learning a trick or two from their counterparts in the IT world?

These are not rhetorical questions. I’m expecting an answer – or at least looking forward to your comments, and maybe even instigating a little cross-breeding for those of you who have friends in the design or construction industry. To wit: Does anybody out there know when iterative development began to take off in the construction industry? For those of you with friends in the design, construction, or property development sectors: Do you know of any examples of iterative construction projects and, if so, what are the challenges and lessons learned?

By the way, I asked these questions of my friend, the architect, in order to see if there were any ‘lessons learned’ that could be applied to the IT world. He told me that the biggest challenge for the design shop, was to avoid making a decision they would later come to regret. This was a real risk, because they were designing while some of the requirements were still unknown. It’s a challenge BAs on iterative projects should all be able to appreciate. Asked how they were mitigating this risk, he summarized their approach as follows:

Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, then …

Choose the option that least constrains the future. That way you minimize the impact of making a wrong decision.

Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.

You can see how these lessons can be immediately applied to IT projects. As to which sector originated the idea of iterative development, one thing is certain: Wherever the iterative idea started, everyone who is doing it – regardless of the sector they’re in – has a lot to learn from each other. Let’s get the conversation started.

Howard Podeswa, author of UML for the IT Business Analyst

Dispatches from the WCBA Conference: Retrospectives

Adrian M. — Wed, 18 Nov 2009 18:51:00 GMT

Dispatches from the WCBA Conference: Retrospectives

“Slow Down to Speed Up: Retrospectives for Improving Product and Process” was the title of one of the workshops I attended during day two of the WCBA conference.

Ellen Gottesdiener, Founder and Principal Consultant, of EBG Consulting tackled the subject of “Retrospectives”.

It was a great presentation and included a number of topics including:

What are Retrospectives?

“Retrospective – a ritual in which the entire project community comes together: reviews the iteration/release/project story (something which just finished), harvests the collective wisdom of the teams, tells the truth without blame or judgment, identifies what to appreciate and improve, understands and forgives its failings, and relishes in its successes.”

In a nutshell, it’s our chance to look back in the rear view mirror and learn from what just took place. The insights gained from retrospectives become the basis for improvement, both immediate and longer term.

Careful using terms such as postmortem (are you assuming you project is dead?)…

In order for a retrospective session to provide value, it must address 5 key questions:

· What did we do well that we might forget if we don’t discuss it soon?

· What did we learn?

· What should we do different next time?

· What still puzzles and intrigues us?

· What needs more in depth discussion and analysis?

When should Retrospectives take place?

The traditional practice for doing retrospectives or postmortems (if your project is dead projects) is at the end of the project. The problem with this approach is that on projects with longer duration the value and benefit of the retrospective diminishes as it is far removed from when most of the project activities took place.

Alternately, retrospectives can be done sooner than the end. For projects which have a set rhythm (regular iterations, regular releases, etc.) a retrospective session can be done at after of each of the repeating phases.

Lastly, you should also consider an ad-hoc retrospective as a valuable tool when you get caught by surprise by a project challenge or other significant unplanned event in the life of the project.

Why Retrospectives?

As with everything else that we do, retrospective must provide value in order to be worth the time and energy. Ellen explored the value proposition of this tool.

In a nutshell, retrospectives are a great way to harvest the collective wisdom of the entire project team by giving everybody a chance to tell the story from their perspective and to discover things that happened on the project that you did not know about.

Retrospective is a great method of free adaptive learning:

· Immediacy – doing the retrospective as soon as possible ensures the recent experiences are sharp in the team’s memory,

· Relevance – the learning is relevant because the team has a common vested interest in the project/milestone/iteration/release what just completed,

· Self-Direction – most of us we don’t like to be told what to do ->retrospectives allows the individual contributors to identify and choose what they want to adapt and change going forward.

Retrospectives that Work

A retrospective is a great community participation-based tool which works because needed change is identified, proposed, and implemented by the project team and not simply shoved down their throats by some executive who is disconnected from the day to day realities of the project.

Successful retrospectives:

· Use data -> how many stories we implemented as opposed to the last iteration, how many test cases per story, how many defects per function point, etc.

· Acknowledge individual feelings -> Remember that feelings do count!

· Have a pre-defined structure –since everybody knows that it will take place, it provides the freedom to participants to identify and implement change without fear or guilt.

A good structure for your retrospective session looks like this:

1. Readying – set the stage

2. Past – gather data

3. Present – generate insights

4. Future – decide what to do

5. Retrospect – close the retrospective (retrospect the retrospective)

Retrospective = basis for change – it’s really a very cheap, yet effective, change management strategy

Agile - the way I like it...

Adrian M. — Mon, 11 May 2009 10:00:00 GMT

This month’s eJournal issue is about Agile and the Agile Business Analyst with a couple of great articles by Ellen Gottesdiener and Scott Ambler exposing upon the agile side of the business.

At ModernAnalyst.com we try really hard to showcase editorial content which is relevant, educational, well balanced, and thought provoking. For the most part, as an editor, I try to stay on the sidelines when it comes to controversial topics such as the Agile vs. Traditional methods.

Yet today I couldn’t resist chiming in! Ouch!

I tend to be a middle of the road guy and, in general, I try not to get stuck on any one of extremes – regardless of subject or topic. My belief is that if it works for me then I’ll continue to use it and I also strongly advice you that if it works for you then you should continue to use it – whatever it is.

But Jason Gorman puts it my better:

If it works, do it
If it works, it works
If it seems to work, it probably works
If it seems to work, it probably works – and might work again

He calls this The Post-Agile Manifesto (disregard the toilet – I haven’t figured that one yet). For more, here’s a Post-Agilism FAQ.

The idea is that fanaticism is not a good thing on either side of the fence. Some agilists when they hear of waterfall projects which succeed, claim the team must have used agile and gave the process a wrong title. Traditionalists who witness successful agile projects call them hacks destined for eventual failure.

As a business analyst, trying to make sense of it all, you might find yourself thinking “agile is bad” because there doesn’t seem to be a well defined role for the BA on an agile team or, perhaps, you’ve started your career as an agile BA and cannot comprehend while anybody in their right mind would want to write a 100 page requirements document.

Unfortunately, the debate between agile and traditional software development processes is alive and well with both side of the camp continuing to fire salvoes at each other.

The truth, as I see it, is probably somewhere in between - as I’m sure you’ll find examples of success stories where:

Agile methods were used to develop large-scale applications,
Traditional methods were employed on small projects,
Agile teams utilized use case narratives,
Traditional teams created user stories to document requirements,
Etc.

The reality is somewhere in between the Traditional Methods and the Agile Manifesto with:

many traditional processes such as the Rational Unified Process (RUP) incorporating agile iterations and other agile concepts, and

agilists turning to more structure and formal processes as witnessed in the Enterprise Unified Process (EUP).

Since this month’s eJournal issue is on Agile – let’s get back there!

Is Agile bad?

No.

However, the type of agile movement that I like is the one that realizes that “agile” is not the end goal.

Creating value is a good goal.

Solving business problems is where it’s at.

Getting the job done is what’s important.

If it works, use it – whatever it is!

Do not be afraid to use what works, don’t shy away from learning something new, and keep on improving our profession and craft regardless what the end process/methodology may be called.

- Adrian

Adrian Marchis

Publisher, ModernAnalyst.com

PS: Are you scared of Agile?

Disgusted with Traditional methods?

What’s on your mind?

I’d love to know!